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REMARKS 

I. Formalities 

Applicant thanks the Examiner for considering the references cited with the 
Supplemental Information Disclosure Statement filed on June 18, 2004. 

II. Status of the Application 

Further to the personal interview conducted with the Examiner on November 3, 2004, 
Applicant hereby submits the present amendment, which addresses each point of objection and 
rejection raised by the Examiner. Favorable reconsideration is respectfully requested. 

By the present amendment, claims 1 and 6 have been amended to more clearly recite the 
features of the present invention. Further, claims 32-33 have been added to provide a more 
varied scope of protection for the present invention. Claims 1-33 are all the claims pending in 
the Application, with claims 1, 6, and 12-29 being in independent form. Claims 1-11 have been 
rejected. 

III. Claim Rejections under 35 U.S.C. §103 

The Examiner has rejected claims 1-11 under 35 U.S.C. § 103(a) as being unpatentable 
over Applicant's admitted prior art, and further in view of U.S. Patent No. 6,453,159 to Lewis 
(hereinafter "Lewis"). Applicant respectfully traverses this rejection for at least the reasons 
stated below, in addition to those reasons previously of record. 

In order for the Examiner to maintain a rejection under 35 U.S.C. §103, Applicant's 
admitted prior art, Lewis, or some combination thereof, must teach or suggest all of the 
limitations of claims 1-11. Applicant respectfully submits that neither Applicant's admitted prior 
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art, Lewis, nor any combination thereof, teaches or suggests all of the limitations recited in 
claims 1-11. 

A. Independent Claim 1 

The Examiner takes the position that Applicant's admitted prior art teaches many of the 
features recited in claim 1, but fails to teach or suggest an authentication server, and the required 
relationship between the access point and the authentication server. See Office Action, page 3, 
lines 4-5. Applicant agrees with the Examiner that Applicant's admitted prior art fails to teach or 
suggest these features. 

Nevertheless, the grounds of rejection apply Lewis, taking the position that Lewis 
discloses an authentication server (allegedly key distribution server 76), which interoperates with 
access points 54 to add a second encryption layer for additional security. Further, the grounds of 
rejection allege that one of ordinary skill would have been motivated to modify Applicant's 
admitted prior art with Lewis in order to maintain a conventional authentication method and 
network integrity between the terminal station and the access point, while adding additional 
security to overcome the potential unauthorized or compromising use of the network taught by 
Lewis. Applicant respectfully disagrees with the grounds of rejection. 



18 



Supplemental Amendment 
U.S. Serial No. 09/680,258 



Attorney Docket No.: Q61120 



Independent claim 1 requires (among other things): 

transmitting an authentication request from 
a STA (terminal station) to an AP (access point), 
wherein said authentication request comprises a 
request from said STA to connect with said LAN; 

requesting authentication of said 
authentication request from said AP to an 
authentication server... 

The grounds of rejection allege that the step 224 of Figure 7, as disclosed in Lewis, 
corresponds to "requesting authentication of said authentication request from said AP to an 
authentication server," as recited in Applicant's claim 1. Applicant respectfully disagrees with 
the grounds of rejection. 

Lewis does not teach or suggest that an authentication request is transmitted from a 
mobile terminal 66, to an access point 54, and that, in turn, authentication of this authentication 
request (i.e., an authentication request from the mobile terminal 66 to the access point 54) is 
requested from the access point 54, to the key distribution server 76. To the contrary, Lewis 
teaches that in step 220, the access point 54 first determines whether a message from a mobile 
terminal 66 has been received. See column 12, line 66 - column 14, line 1; Figure 7. If so, 
Lewis teaches that, then, in step 222, the access point 54 determines whether, or not, the message 
it received from the mobile terminal 66, is encrypted using the current ENCRYPT key. See 
column 13, lines 12-15; Figure 7. Further, Lewis teaches that if the message the access point 54 
received from the mobile terminal 66 is encrypted using the current ENCRYPT key, then the 
access point 54 passes this message on to the system backbone 52, and then on to its intended 
destination on the system backbone 52. See column 13, lines 12-15; Figure 7. 
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The grounds of rejection allege that the message from the mobile terminal 66 to the 
access point 54, which is ultimately passed on to the system backbone 52, as taught in step 224 
of Lewis, corresponds to "an authentication request," as recited in claim 1. However, even if this 
message sent from the mobile terminal 66 to the access point 54 did correspond to "an 
authentication request," as recited in claim 1, which Applicant firmly submits it does not for at 
least the reasons set forth below, Lewis does not teach or suggest requesting authentication of 
this alleged authentication request from the access point 54 to the key distribution server 76. In 
fact, steps 222 and 224 of Lewis teaches quite the opposite — determining whether a message is 
encrypted using the current ENCRYPT key, and if it is, directly forwarding this message to its 
intended destination without any processing whatsoever conducted by the key distribution server 
76. 

Furthermore, as taught in Lewis, the only instance when an access point 54 transmits any 
sort of message to the key distribution server 76, is when an access point 54 determines that the' 
destination address of a message received from a mobile terminal 66 specifies the key 
distribution server 76. See column 13, lines 26-41. For example, Lewis teaches that the 
destination address of a message from a mobile terminal 66 specifies the key distribution server 
76 when the mobile terminal 66 sends a request for the current ENCRYPT key. See column 13, 
lines 29-41. 

However, this request sent by a mobile terminal 66 for the current ENCRYPT key, which 
is passively forwarded by an access point 54 to the key distribution server 76, does not even 
remotely resemble requesting authentication of an authentication request from an access point to 
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an authentication server, wherein said authentication request comprises a request from an STA to 
connect with a LAN, as recited in claim 1 . 

More particularly, as taught in Lewis, a request sent by a mobile terminal 66 for the 
current ENCRYPT key clearly does not correspond to "an authentication request," as recited in 
claim 1. Claim 1 expressly requires that "said authentication request comprises a request from 
said STA to connect with said LAN." In contrast to the requirements of claim 1, a request for 
the current ENCRYPT key sent by the mobile terminal 66, addressed to the key distribution 
server 76, is a request for a data string of auxiliary information that will enable the mobile 
terminal 66 to communicate with the access point 54 according to a secure encrypted exchange 
format. See column 2, lines 44-51; column 9, lines 30-35. 

Hence, a request, sent by a mobile terminal 66, for the current ENCRYPT key plainly 
does not comprise a request from an STA to connect with a LAN, as required by claim 1 . 
Therefore, Lewis does not teach, and is incapable of suggesting, requesting authentication of an 
authentication request from an AP to an authentication server, wherein said authentication 
request comprises a request from an STA to connect with a LAN, as recited in claim 1 . 

Moreover, Applicant submits that it would not have been obvious to one of ordinary skill 
in the art to modify the combination of Applicant's admitted prior art and Lewis to arrive at the 
present invention. In fact, Lewis explicitly teaches away from the feature of requesting 
authentication of an authentication request from an access point to an authentication server, 
wherein said authentication request comprises a request from an STA to connect with a LAN, as 
recited in claim 1. Contrary to the recitations of claim 1, Lewis teaches that authentication 
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requests from devices (e.g., mobile terminal 66) are always authenticated by the access point 54 
itself using conventional methods. 

Specifically, Lewis teaches that messages received from a device by the access point 54 
are authenticated by the access point 54 itself, by determining whether the source of the received 
message is included in the clear table 126. See column 13, lines 17-22. If the device is included 
in the clear table 126, "it indicates that the device sending the message to the access point 54 is 
authorized and is permitted to communicate in a non-secure manner." Column 13, lines 23-26. 
Accordingly, Lewis teaches that the access point 54 then forwards the message onto the system 
backbone 52 via step 224. See column 13, lines 26-28; Figure 7. 

Further, Lewis teaches that in the event that a message received by an access point 54 
from a device are encrypted using the current ENCRYPT key, such messages are also 
authenticated for access to the system backbone 52 by the access point 54, by determining 
whether the message is, in fact, encrypted using the current ENCRYPT key. See column 13, 
lines 12-13. If so, Lewis teaches that the access point 54 decrypts the message and passes the 
decrypted message onto the system backbone 52, and to its intended destination, as shown in 
step 224. See column 12, lines 12-15; Figure 7. 

Therefore, Lewis plainly teaches away from the feature of requesting authentication of 
any authentication requests from an access point 54 to an authentication server, in that, Lewis 
teaches that messages received from a device by the access point 54 are always authenticated by 
the access point 54 itself. 
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Therefore, much like the conventional systems discussed in the present specification, the 
hardware and software resources of the access point 54 are always required to execute the 
authentication function of each device. And, as discussed in the present specification, it is 
difficult for access points to provide MAC address tables for large numbers of terminals. See 
Specification page 3, lines 15-23. As a result, Lewis does not teach, and is incapable of 
suggesting, modifying the combination of Applicant's admitted prior art and Lewis to achieve 
* the feature of requesting authentication of an authentication request from an access point to an 
authentication server, wherein said authentication request comprises a request from an STA to 
connect with a LAN, as recited in claim 1 . 

Additionally, in the Advisory Action dated September 8, 2004 (hereinafter "Advisory 
Action"), the grounds of rejection maintain the allegations that Lewis discloses the use of a 
media access control ("MAC") address as claimed in the present application. In particular, the 
grounds of rejection allege that the "network addresses or ID's" of the mobile terminals taught in 
Lewis can be considered MAC addresses, since these identifiers are used to control which 
packets are transmitted over the network media. See Advisory Action page 2, lines 8-14. 

Applicant emphatically disagrees with the grounds of rejection, especially the Examiner's 
interpretation of the term "a MAC address." Applicant reminds the Examiner that contrary to the 
Examiner's assertion that "the Examiner must interpret the claims in there broadest sense," the 
MPEP explicitly requires that "[djuring patent examination, the pending claims must be given 
their broadest reasonable interpretation consistent with the specification " (emphasis added). 
MPEP §2111. The MPEP also mandates that "[t]he broadest reasonable interpretation of the 
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claims must also be consistent with the interpretation that those skilled in the art would reach " 
(emphasis added). MPEP §2111. 

First, the Examiner's interpretation of a MAC address is not reasonable, and is plainly 
inconsistent with the interpretation reached by those skilled in the art. As explained in the 
previous Amendment filed on March 17, 2004, and again in the Amendment filed on July 27, 
2004, the ordinary and accepted meaning of the term "MAC address" is a globally unique 
hardware identifier, which is permanently assigned when a device is manufactured. As 
exemplary evidence of this accepted definition of "a MAC address," Applicant previously 
submitted copies of the definition of "a MAC address" from various technical dictionaries. In 
light of these exemplary definitions, it is clear that one skilled in the art would interpret a "MAC 
address" to mean a globally unique hardware identifier, which is permanently assigned when a 
device is manufactured. 

Therefore, the Examiner's interpretation of "a MAC address" to mean any address that 
provides access to the network media, is plainly inconsistent with the interpretation reached by 
those skilled in the art, and is therefore erroneous. To the contrary, the "network address or ID" 
taught in Lewis plainly cannot be a MAC address because the "network address or ID" taught in 
Lewis is a local logical identifier that requires manual input by a system administrator. Further, 
according to the accepted meaning of the term in the art, "a MAC address" typically comprises a 
48-bit hexadecimal number (12 characters). In contrast, the identifiers taught in Lewis (i.e., 
"MT1" or "MT2") are clearly not 48-bit hexadecimal numbers. 
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Second, the Examiner's interpretation of "a MAC address" to mean any address that 
provides access to the network media, is plainly inconsistent with the specification of the present 
application. To the contrary, for the reasons set forth in the previous Amendments, taken in its 
proper context, the passage of the present specification cited by the Examiner (page 11, lines 28- 
29) that "the MAC address is defined as a user name or calling station ID on the authentication 
protocol (RADIUS)," merely connotes that the particular value of the MAC address may be used 
- as the respective values for the "user name" or the "calling station ID" attributes of the 
authentication information that is used in the RADIUS protocol. 

As evidence that this is the proper interpretation of the passage on page 11, lines 28-29, 
Applicant submits herewith a copy of Request for Comments: 2138, entitled "Remote 
Authentication Dial In User Service (RADIUS)" (hereinafter "RFC 2138"). RFC 2138 is the 
standard which describes and specifies the RADIUS protocol. Applicant notes that the term 
"MAC address" does not appear anywhere in RFC 2138, nor is it defined anywhere therein. As 
a result, it is clear that, in contrast to the Examiner's allegations, the MAC address is not defined 
as being, or consisting of, a user name or calling station ID on the authentication protocol 
(RADIUS). To the contrary, the term "MAC address" is not defined on the RADIUS protocol at 
all. 

Hence, it is clear that, taken in its proper context, the statement on page 1 1, lines 28-29 
merely reflects Applicant's intent to clarify that the term "MAC address," which is defined in the 
present application consistent with its ordinary accustomed meaning, is used as a user name or a 
calling station ID on the authentication protocol RADIUS. 
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Furthermore, numerous portions of the present specification clearly indicate that the term 
"MAC address" is used consistent with the ordinary and accustomed meaning of the term 
reached by those skilled in the art, namely, that "a MAC address" means a globally unique 
hardware identifier, which is permanently assigned when a device is manufactured. For instance, 
the present specification makes it clear that "a MAC address of the STA 1 is included in a MAC 
frame as a source address," and that this MAC frame is defined by IEEE 802.1 1. Specification, 
- page 2, lines 21-22; see Specification, page 2, lines 5-22. Moreover, the specification clearly 
explains that a MAC address is used as an ID for authentication when a request is sent to an 
authentication server. See Specification, page 8, lines 23-28. Indeed, both of these exemplary 
passages make it abundantly clear that the term "a MAC address" is used consistently throughout 
the present specification in accordance with the term's ordinary and accustomed meaning as 
reached by those skilled in the art. 

Accordingly, in light of the ordinary and accustomed meaning of the term "MAC 
address," it is clear that Lewis merely teaches that the key distribution server 76 distributes the 
current ENCRYPT key to mobile terminals 66 based on the contents of system device table 152, 
which does not include a MAC address . Further, the "network address or ID" taught in Lewis 
does not inherently include a MAC address because, for the reasons set forth above, the network 
address or ID taught in Lewis does not necessarily include a MAC address — a determination for 
which, in relying upon the theory of inherency, the Examiner is required by MPEP §21 12 to 
provide a basis in fact and/or technical reasoning. To the contrary, the "network address or ID" 
taught in Lewis is a local logical identifier that requires manual input by a system administrator, 
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whereas a MAC address is a globally unique hardware identifier which is permanently assigned 
when a device is manufactured and typically consists of a 48-bit hexadecimal number. 

Accordingly, Lewis does not teach, and is incapable of suggesting, that the key 
distribution server 76 checks an authentication request from a mobile station 66 to an access 
point 54, based on a MAC address of a mobile station 66. Therefore, neither Applicant's 
admitted prior art, Lewis, nor any combination thereof, teaches or suggests an authentication 
- method comprising checking an authentication request at an authentication server based on a 
media access control ("MAC") address of a terminal station, as required by Applicant's claim 1. 

For at least the reasons set forth above, and for the reasons previously set forth in the 
Amendment filed on July 24, 2004, Lewis fails to teach or suggest all the recitations of 
independent claim 1 . Thus, Applicant respectfully submits that independent claim 1 is 
patentable over Applicant's admitted prior art, Lewis, and any combination thereof, for at least 
these reasons. Further, Applicant respectfully submits that the dependent claims 2-5 are 
allowable, at least by virtue of their dependency on claim 1 . Consequently, Applicant 
respectfully requests that the Examiner withdraw this rejection. 

B. Independent Claim 6 

Independent claim 6 requires (among other things): 

...one of said plural APs receives an 
authentication request from one of said plural 
STAs... 

said authentication server which checks said 
authentication request from one of said STAs... 

wherein said authentication request 
comprises a request from one of said plural STAs 
to connect with said LAN. 
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In view of the similarity between these requirements and the requirements discussed 
above with respect to independent claim 1, Applicant respectfully submits that the foregoing 
arguments as to the patentability of independent claim 1 apply at least by analogy to claim 6. As 
such, it is respectfully submitted that claim 6 is patentably distinguishable over Applicant's 
admitted prior art, Lewis, and any combination thereof, for at least these reasons. Further, 
Applicant submits that the dependent claims 7-11 are allowable at least by virtue of their 
* dependency on claim 6. Thus, the allowance of these claims is respectfully solicited of the 
Examiner. 

IV. Claims 12-31 

The Examiner has not set forth any grounds of rejection with respect to claims 12-31 . As 
a result, Applicant submits that claims 12-31 are allowable at least by virtue of the recitations set 
forth therein. 

V. New Claims 

Claims 32-33 are hereby added and are fully supported at least by page 2, lines 5-22, and 
page 8, lines 23-28 of the present specification for at least the reasons set forth above. Claims 
32-33 are respectfully submitted to be allowable at least by virtue of their dependency and by 
virtue of the recitations set forth therein. 

VI. Conclusion 

In view of the above, reconsideration and allowance of this application are now believed 
to be in order, and such actions are hereby solicited. If any points remain in issue which the 
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Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly requested to contact the undersigned at the telephone number listed below. 

The USPTO is directed and authorized to charge all required fees, except for the Issue 
Fee and the Publication Fee, to Deposit Account No. 19-4880. Please also credit any 
overpayments to said Deposit Account. 



Respectfully submitted, 



SUGHRUE MION, PLLC 
Telephone: (202) 293-7060 
Facsimile: (202) 293-7860 



Andrew J. Taska 
Registration No. 54,666 



WASHINGTON OFFICE 



23373 
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Remote Authentication Dial In User Service (RADIUS) 



Status of this Memo 

This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 



Abstract 



This document describes a protocol for carrying authentication, 
authorization, and configuration information between a Network Access 
Server which desires to authenticate its links and a shared 
Authentication Server. 



Implementation Note 



This memo documents the RADIUS protocol. There has been some 
confusion in the assignment of port numbers for this protocol. The 
early deployment of RADIUS was done using the erroneously chosen port 
number 1645, which conflicts with the "da tame tries" service. The 
officially assigned port number for RADIUS is 1812. 
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1. Introduction 

Managing dispersed serial line and modem pools for large numbers o.f 
users can create the need for significant administrative support. 
Since modem pools are by definition a link to the outside world, they 
require careful attention to security, authorization and accounting. 
This can be best achieved by managing a single "database" of users, 
which allows for authentication (verifying user name and password) as 
well as configuration information detailing the type of service to 
deliver to the user (for example, SLIP, PPP,' telnet, rlogin) . 

Key features of RADIUS are: 

Client/Server Model 

A Network Access Server (NAS) operates as a client of RADIUS. The 
client is responsible for passing user information to designated 
RADIUS servers, and then acting on the response which is returned. 

RADIUS servers are responsible for receiving user connection 
requests, authenticating the user, and then returning all 
configuration information necessary for the client to deliver 
service to the user. 

A RADIUS server can act as a proxy client to other RADIUS servers 
or other kinds of authentication servers. 

Network Security 

Transactions between the client and RADIUS server are 
authenticated through the use of a shared secret, which is never 
sent over the network. In addition, any user passwords are sent 
encrypted between the client and RADIUS server, to eliminate the 
possibility that someone snooping on an unsecure network could 
determine a user's password. 
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Flexible Authentication Mechanisms 

The -RADIUS server can support a variety of methods to authenticate 
a user. When it is provided with the user name and original 
password given by the user, it can support PPP PAP or CHAP, UNIX 
login, and other authentication mechanisms. 

Extensible Protocol 



□ 

RFC 2138 



RADIUS 



April 1997 
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All transactions are comprised of variable length Attribute- 
Length-Value 3-tuples. New attribute values can be added without 
disturbing existing implementations of the protocol. 

1.1. Specification of Requirements 

In this document, several words are used to signify the requirements 
of the specification. These words are often capitalized. 

MUST This word, or the adjective "required", means that the 

definition is an absolute requirement of the specification. 

MUST NOT This phrase means that the definition is an absolute 
prohibition of the specification. 

SHOULD' This word, or the adjective "recommended", means that there 
may exist valid reasons in particular circumstances to 
ignore this item, but the full implications must be 
understood and carefully weighed before choosing a 
different course. 



MAY This word, or the adjective "optional", means that this 

item is one of an allowed set of alternatives. An 
implementation which does not include this option MUST be 
prepared to interoperate with another implementation which 
does include the option. 
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1.2. Terminology 

This document frequently uses the following terms: 

service The NAS provides a, service to the dial-in user, such as PPP 
or Telnet . 

session Each service provided by the NAS to a dial-in user 

constitutes a session, with the beginning of the session 
defined as the point where service is first provided and 
the end of the session defined as the point where service 
is ended. A user may have multiple sessions in parallel or 
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series if the NAS supports that. 

silently discard 

This means the implementation discards the packet without 
further processing. The implementation SHOULD provide the 
capability of logging the error, including the contents of 
the silently discarded packet, and SHOULD record the event 
in a statistics counter. 

2. Operation 

When a client is configured to use RADIUS, any user of the client 
presents authentication information to the client. This might be 
with a customizable login prompt, where the user is expected to enter 
their username and password. Alternatively, the user might use a 
link framing protocol such as the Point-to-Point Protocol (PPP) , 
which has authentication packets which carry this information. 

Once "the client has obtained such information, it may choose to 
authenticate using RADIUS. To do so, the client creates an "Access- 
Request" containing such Attributes as the user's name, the user's 
password, the ID of the client and the Port ID which the user is 
accessing. When a password is present, it is hidden using a method 
based on the RSA Message Digest Algorithm MD5 [1] . 

The Access-Request is submitted to the RADIUS server via the network. 
If no response is returned within a length of time, the request is 
re-sent a number of times. The client can also forward requests to 
an alternate server or servers in the event that the primary server 
is down or unreachable. An alternate server can be used either after 
a number of tries to the primary server fail, or in a round-robin 
fashion. Retry and fallback algorithms are the topic of current 
research and are not specified in detail in this document. 
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Once the RADIUS server receives the request, it validates the sending 
client. A request from a client for which the RADIUS server does not 
have a shared secret should be silently discarded. If the client is 
valid, the RADIUS server consults a database of users to find the 
user whose name matches the request. The user entry in the database 
contains a list of requirements which must be met to allow access for 
the user. This always includes verification of the password, but can 
also specify the client (s) or port(s) to which the user is allowed 
access . 

The RADIUS server MAY make requests of other servers in order to 
satisfy the request, in which case it acts as a client. 

If any condition is not met, the RADIUS server sends an "Access- 
Reject" response indicating that this user request is invalid. If 
desired, the server MAY include a text message in the Access -Reject 
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which MAY be displayed by the client to the user. No other 
Attributes are permitted in an Access-Reject. 

If all conditions are met and the RADIUS server wishes to issue a 
challenge to which the user must respond, the RADIUS server sends an 
"Access-Challenge" response. It MAY include a text message to be 
displayed by the client to the user prompting for a response to the 
challenge, and MAY include a State attribute. If the client receives 
an Access-Challenge and supports challenge/response it MAY display 
the text message, if any, to the user, and then prompt the user for a 
response. The client then re-submits its original Access-Request 
with a new request ID, with the User-Password Attribute replaced by 
the response (encrypted) , and including the State Attribute from the 
Access-Challenge, if any. Only 0 or 1 instances of the State 
Attributes should be present in a request. The server can respond to 
this new Access-Request with either an Access-Accept, an Access- 
Reject, or another Access-Challenge. 

If all .conditions are met, the list of configuration values for the 
user are placed into an "Access-Accept" response. These values 
include the type of service (for example: SLIP, PPP, Login User) and 
all necessary values to deliver the desired service. For SLIP and 
PPP, this may include values such as IP address, subnet mask, MTU, 
desired compression, and desired packet filter identifiers. For 
character mode users, this may include values such as desired 
protocol and host. 
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2.1. Challenge/Response 

In challenge/response authentication, the user is given an 
unpredictable number and challenged to encrypt it and give back the 
result. Authorized users are equipped with special devices such as 
smart cards or software that facilitate calculation of the correct 
response with ease. Unauthorized users, lacking the appropriate 
device -or software and lacking knowledge of the secret key necessary 
to emulate such a device or software, can only guess at the response. 

The Access-Challenge packet typically contains a Reply-Message 
including a challenge to be displayed to the user, such as a numeric 
value unlikely ever to be repeated. Typically this is obtained from 
an external server that knows what type of authenticator should be in 
the possession of the authorized user and can therefore choose a 
random or non-repeating pseudorandom number of an appropriate radix 
and length. 

The user then enters the challenge into his device (or software) and 
it calculates a response, which the user enters into the client which 
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forwards it to the RADIUS server via a second Access-Request. If the 
response matches the expected response the RADIUS server replies with 
an Access-Accept, otherwise an Access-Reject. 

Example: The NAS sends an Access-Request packet to the RADIUS Server 
with NAS-Identif ier # NAS-Port, User-Name, User-Password (which may 
just be a fixed string like "challenge" or ignored) . The server 
sends back an Access-Challenge packet with State and a Reply-Message 
along the lines of "Challenge 12345678, enter your response at the 
prompt" which the NAS displays. The NAS prompts for the response and 
sends a NEW Access-Request to the server (with a new ID) with NAS- 
Identifier, NAS-Port, User-Name, User-Password (the response just 
entered by the user, encrypted) , and the same State Attribute that 
came with the Access-Challenge. The server then sends back either an 
Access-Accept or Access-Reject based on whether the response matches 
what it should be, or it can even send another Access-Challenge. 

2.2. Interoperation with PAP and CHAP 

For PAP, the NAS takes the PAP ID and password and sends them in an 
Access-Request packet as the User-Name and User-Password. The NAS MAY 
include the Attributes Service-Type = Framed-User and Framed- Protocol 
= PPP as a hint to the RADIUS server that PPP service is expected. 

For CHAP, the NAS generates a random challenge (preferably 16 octets) 
and sends it to the user, who returns a CHAP response along with a 
CHAP ID and CHAP username. The NAS then sends an Access-Request 
packet to the RADIUS server with the CHAP username as the User-Name 
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and with the CHAP ID and CHAP response as the CHAP-Password 
(Attribute 3) . The random challenge can either be included in the 
CHAP-Challenge attribute or, if it is 16 octets long, it can be 
placed in the Request Authenticator field of the Access-Request 
packet.. The NAS MAY include the Attributes Service-Type = Framed- 
User and Framed-Protocol = PPP as a hint to the RADIUS server that 
PPP service is expected. 

The RADIUS server looks up a password based on the User-Name, 
encrypts the challenge using MD5 on the CHAP ID octet, that password, 
and the CHAP challenge (from the CHAP-Challenge attribute if present, 
otherwise from the Request Authenticator) , and compares that result 
to the CHAP-Password. If they match, the server sends back an 
Access-Accept, otherwise it sends back an Access-Reject. 

If the RADIUS server is unable to perform the requested 
authentication it should return an Access-Reject. For example, CHAP 
requires that the user's password be available in cleartext to the 
server so that it can encrypt the CHAP challenge and compare that to 
the CHAP response. If the password is not available in cleartext to 
the RADIUS server then the server MUST send an Access-Reject to the 
client. 



2.3. Why UDP? 
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A frequently asked question is why RADIUS uses UDP instead of TCP as 
a transport protocol. UDP was chosen for strictly technical reasons. 

There are a number of issues which must be understood. RADIUS is a 
transaction based protocol which has several interesting 
characteristics : 

1. If the request to a primary Authentication server fails, a 
secondary server must be queried. 

To meet this requirement, a copy of the request must be kept 
above the transport layer to allow for alternate transmission. 
This means that retransmission timers are still required. 

2 . The timing requirements of this particular protocol are 
significantly different than TCP provides. 

At one extreme, RADIUS does not require a "responsive" 
detection of lost data. The user is willing to wait several 
seconds for the authentication to complete. The generally 
"aggressive TCP retransmission (based on average round trip 
time) is not required, nor is the acknowledgement overhead of 
TCP. 
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At the other extreme, the user is not willing to wait several 
minutes for authentication. Therefore the reliable delivery of 
TCP data two minutes later is not useful. The faster use of an 
alternate server allows the user to gain access before giving 
up. 

3. The stateless nature of this protocol simplifies the use of UDP. 

Clients and servers come and go. Systems are rebooted, or are 
power cycled independently. Generally this does not cause a 
problem and with creative timeouts and detection of lost TCP 
connections, code can be written to handle anomalous events. 
UDP however completely eliminates any of this special handling. 
Each client and server can open their UDP transport just once 
and leave it open through all types of failure events on the 
network. 

4. UDP simplifies the server implementation. 

In the earliest implementations of RADIUS, the server was 
single threaded. This means that a single request was 
received, processed, and returned. This was found to be 
unmanageable in environments where the back-end security 
mechanism took real time (1 or more seconds) . The server 
request queue would fill and in environments where hundreds of 
people were being authenticated every minute, the request 
turn-around time increased to longer that users were willing to 
wait (this was especially severe when a specific lookup in a 
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database or over DNS took 30 or more seconds) . The obvious 
solution was to make the server multi- threaded. Achieving this 
was simple with UDP. Separate processes were spawned to serve 
each request and these processes could respond directly to the 
client NAS with a simple UDP packet to the original transport 
of the client. 

It's not all a panacea. As noted, using UDP requires one thing 
which is built into TCP: with UDP we must artificially manage 
retransmission timers to the same server, although they don't 
require the same attention to timing provided by TCP. This one 
penalty is a small price to pay for the advantages of UDP in 
this protocol. 

Without TCP we would still probably be using tin cans connected 
by string. But for this particular protocol, UDP is a better 
choice . 
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3 . Packet Format 

Exactly one RADIUS packet is encapsulated in the UDP Data field [2], 
where the UDP Destination Port field indicates 1812 (decimal) . 

When a reply is generated, the source and destination ports are 
reversed. 

This memo documents the RADIUS protocol. There has been some 
confusion in the assignment of port numbers for this protocol. The 
early deployment of RADIUS was done using the erroneously chosen port 
number 1645, which conflicts with the "da tame tries" service. The 
officially assigned port number for RADIUS is 1812. 

A summary of the RADIUS data format is shown below. The fields are 
transmitted from left to right. 

0 1 2*3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Code | Identifier | Length | 

+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+_+-+-+-^ 

| Authenticator j 

j j 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Attributes . . . 

+_+_+_+_+_+_+_+_+_+_+_+_+_ 

Code 
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The Code field is one octet, and identifies the type of RADIUS 
packet. When a packet is received with an invalid Code field, 
silently discarded. 



it is 



RADIUS Codes (decimal) are assigned as follows: 

1 Access-Request 

2 Access-Accept 

3 Access-Reject 

4 Accounting-Request 

5 Accounting-Response 

11 Access -Challenge 

12 Status-Server (experimental) 

13 • Status-Client (experimental) 
255 -Reserved 
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Codes 4 and 5 are covered in the RADIUS Accounting document [9] , and 
are not further mentioned here. Codes 12 and 13 are reserved for 
possible use, but are not further mentioned here. 

Identifier 

The Identifier field is one octet, and aids in matching requests and 
replies . 

Length 

The Length field is two octets. It indicates the length of the 
packet including the Code, Identifier, Length, Authenticator and 
Attribute fields. Octets outside the range of the Length field 
should be treated as padding and should be ignored on reception. If 
the packet is shorter than the Length field indicates, it should be 
silently discarded. The minimum length is 2 0 and maximum length is 
4096. 

Authenticator 

The Authenticator field is sixteen (16) octets. The most significant 
octet is transmitted first. This value is used to authenticate the 
reply from the RADIUS server, and is used in the password hiding 
algorithm. 

Request Authenticator 

In Access-Request Packets, the Authenticator value is a 16 octet 
random number, called the Request Authenticator. The value SHOULD 
be unpredictable and unique over the lifetime of a secret (the 
password shared between the client and the RADIUS server) , since 
repetition of a request value in conjunction with the same secret 
would permit an attacker to reply with a previously intercepted 
response. Since it is expected that the same secret MAY be used 
to authenticate with servers in disparate geographic regions, the 
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Request Authenticator field SHOULD exhibit global and temporal 
uniqueness . 

The Request Authenticator value in an Access-Request packet SHOULD 
also be unpredictable, lest an attacker trick a server into 
responding to a predicted future request, and then use the 
response to masquerade as that server to a future Access-Request. 
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Although protocols such as RADIUS are incapable of protecting 
against theft of an authenticated session via realtime active 
wiretapping attacks, generation of unique unpredictable requests 
can protect against a wide range of active attacks against 
authentication . 



The NAS and RADIUS server share a secret . That shared secret 
followed by the Request Authenticator is put through a one-way MD5 
hash to create a 16 octet digest value which is xored with the 
password entered by the user, and the xored result placed in the 
User-Password attribute in the .Access-Request packet. See the 
entry for User-Password in the section on Attributes for a more 
detailed description. 

Response Authenticator 



The value of the Authenticator field in Access-Accept, Access- 
Reject, and Access-Challenge packets is called the Response 
Authenticator, and contains a one-way MD5 hash calculated over a 
stream of octets consisting of: the RADIUS packet, beginning with 
the Code field, including the Identifier, the Length, the Request 
Authenticator field from the Access-Request packet, and the 
response Attributes, followed by the shared secret. That is, 
Resp'onseAuth = MD5 (Code+ID+Length+RequestAuth+Attributes+Secret ) 
where + denotes concatenation. 



Administrative Note 



The secret (password shared between the client and the RADIUS server) 
SHOULD be at least as large and unguessable as a well -chosen 
password. It is preferred that the secret be at least 16 octets. 
This is to ensure a sufficiently large range for the secret to 
provide protection against exhaustive search attacks. A RADIUS 
server SHOULD use the source IP address of the RADIUS UDP packet to 
decide which shared secret to use, so that RADIUS requests can be 
proxied. 

When using a forwarding proxy, the proxy must be able to alter the 
packet as it passes through in each direction - when the proxy 
forwards the request, the proxy can add a Proxy-State Attribute, and 
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when 'the proxy forwards a response, it removes the Proxy-State 
Attribute. Since Access-Accept and Access-Reject replies are 
authenticated on the entire packet contents, the stripping of the 
Proxy-State attribute would invalidate the signature in the packet - 
so the proxy has to re-sign it. 

Further details of RADIUS proxy implementation are outside the scope 
of this document. 
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Attributes 

Many 'Attributes may have multiple instances, in such a case the order 
of Attributes of the same Type SHOULD be preserved. The order of 
Attributes of different Types is not required to be preserved. 

In the section below on "Attributes" where the text refers to which 
packets an attribute is allowed in, only packets with Codes 1, 2, 3 
and 11 and attributes defined in this document are covered in this 
document. A summary table is provided at the end of the "Attributes" 
section. To determine which Attributes are allowed in packets with 
codes 4 and 5 refer to the RADIUS Accounting document [9] . 

4 . Packet Types 

The RADIUS Packet type is determined by the Code field in the first 
octet of the Packet. 

4.1. Access-Request 

Description 

Access-Request packets are sent to a RADIUS server, and convey 
information used to determine whether a user is allowed access to 
a specific NAS, and any special services requested for that user. 
An implementation wishing to authenticate a user MUST transmit a 
RADIUS packet with the Code field set to 1 (Access-Request) . 

Upon receipt of an Access-Request from a valid client, an 
appropriate reply MUST be transmitted. 

An Access-Request MUST contain a User-Name attribute. It SHOULD 
contain either a NAS -IP- Address attribute or NAS-Identif ier 
attribute (or both, although that is not recommended) . It MUST 
contain either a User-Password attribute or CHAP-Password 
attribute. It SHOULD contain a NAS-Port or NAS-Port-Type 
attribute or both unless the type of access being requested does 
not involve a port or the NAS does not distinguish among its 
ports . 

An Access-Request MAY contain additional attributes as a hint to 
the server, but the server is not required to honor the hint. 

When a User-Password is present, it is hidden using a method based 
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on the RSA Message Digest Algorithm MD5 [1] . 



A summary of the Access -Request packet format is shown below. The 
fields are transmitted from left to right. 
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0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Code | Identifier | Length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

i , • I 

| Request Authenticator | 

i i 
i i 

+ _ + _ + '_ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

| Attributes . . . 
+-+-+-+-+-+-+-+-+-+-+-+-+- 



Code 

1 for Access-Request. 
Identifier 



The Identifier field MUST be changed whenever the content of the 
Attributes field changes, and whenever a valid reply has been 
received for a previous request. For retransmissions, the 
Identifier MUST remain unchanged. 

Request Authenticator 



The Request Authenticator value MUST be changed each time a new 
Identifier is used. 

Attributes 



The Attribute field is variable in length, and contains the list 
of Attributes that are required for the type of service, as well 
as any desired optional Attributes . 

4.2. Access-Accept 

Description 

Access-Accept packets are sent by the RADIUS server, and provide 
specific configuration information necessary to begin delivery of 
service to the user. If all Attribute values received in an 
Access-Request are acceptable then the RADIUS implementation MUST 
transmit a packet with the Code field set to 2 (Access-Accept) . 
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On reception of an Access -Accept , the Identifier field is matched 
with a pending Access-Request. Additionally, the Response 
Authenticator field MUST contain the correct response for the 
pending Access-Request. Invalid packets are silently discarded. 

A summary of the Access-Accept packet format is shown below. The 
fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + ^ + - + - + - + - + - + - + -+- + - + - + - + - + - + --1-- + - + - + 

| Code | Identifier | Length | 

+ _ + _ + _ + _+_ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

i - I 

| Response Authenticator I 



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Attributes . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+- 

Code 

2 for Access-Accept. 
Identifier 

The Identifier field is a copy of the Identifier field of the 
Access-Request which caused this Access-Accept. 

Response Authenticator 

The Response Authenticator value is calculated from the Access- 
Request value, as described earlier. 

Attributes 

The Attribute field is variable in length, and contains a list of 
zero or more Attributes. 
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4.3. Access-Reject 
Description 

If any value of the received Attributes is not acceptable, then 
the RADIUS server MUST transmit a packet with the Code field set 
to 3 (Access-Reject) . It MAY include one or more Reply-Message 
Attributes with a text message which the NAS MAY display to the 
user. 

A summary of the Access-Reject packet format is shown below. The 
fields are transmitted from left to right. 

0 12 3 

01 '2 34567890123456789012345678901 
+ _ + _ + „ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

I Code | Identifier | Length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+-+-+-+-+-+-+-+-+-+~+-+-+-+~+-+-+ 

! i 

| Response Authenticator I 



^ i i 1 1 i ■ 1 J i 1 * 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J 1 1 1 1 1- 

| Attributes . . . 
+-+-+-+-+-+-+-+-+-+-+-+-+- 

Code 

3 for Access-Reject. 
Identifier 

The Identifier field is a copy of the Identifier field of the 
Access-Request which caused this Access-Reject. 

Response Authenticator 

The Response Authenticator value is calculated from the Access- 
Request value, as described earlier. 

Attributes 

The Attribute field is variable in length, and contains a list of 
zero or more Attributes. 
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4.4. Access-Challenge 



Description 

If the RADIUS server desires to send the user a challenge 
requiring a response, then the RADIUS server MUST respond to the 
Access-Request by transmitting a packet with the Code field set to 
11 (Access-Challenge) . 

The Attributes field MAY have one or more Reply-Message 
Attributes, and MAY have a single State Attribute, or none. No 
other Attributes are permitted in an Access-Challenge. 

On receipt of an Access-Challenge, the Identifier field is matched 
with a pending Access-Request. Additionally, the Response 
Authenticator field MUST contain the correct response for the 
pending Access-Request. Invalid packets are silently discarded. 

if the NAS does not support challenge/response, it MUST treat an 
Access-Challenge as though it had received an Access-Reject 
instead. 

If the NAS supports challenge/response, receipt of a valid 
Access-Challenge indicates that a new Access-Request SHOULD be 
sent. The NAS MAY display the text message, if any, to the user, 
and then prompt the user for a response. It then sends its 
original Access-Request with a new request ID and Request 
Authenticator, with the User-Password Attribute replaced by the 
user's response (encrypted), and including the State Attribute 
from the Access-Challenge, if any. Only 0 or 1 instances of the 
State Attribute can be present in an Access-Request . 

A NAS which supports PAP MAY forward the Reply-Message to the 
dialin client and accept a PAP response which it can use as though 
the user had entered the response. If the NAS cannot do so, it 
should treat the Access-Challenge as though it had received an 
Access-Reject instead. 
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A summary of the Access-Challenge packet format is shown below. The 
fields are transmitted from left to right. 
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01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Code | Identifier | Length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Response Authenticator | 



+ _ + _ + _ + _ + _ + _ + _-)-_ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

| Attributes . . . 
+-+-+-+-+-+-+-+-+-+-+-+-+- 

Code 

11 for Access-Challenge. 

Identifier 
* 

The" Identifier field is a copy of the Identifier field of the 
Access-Request which caused this Access-Challenge. 

Response Authenticator 

The Response Authenticator value is calculated from the Access- 
Request value, as described earlier. 

Attributes 

The Attributes field is variable in length, and contains a list of 
zero or more Attributes. 

5. Attributes 

RADIUS Attributes carry the specific authentication, authorization, 
information and configuration details for the request and reply. 

Some Attributes MAY be included more than once. The effect of this 
is Attribute specific, and is specified in each Attribute 
description. 

The end of the list of Attributes is indicated by the Length of the 
RADIUS packet. 
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A summary of the Attribute format is shown below. The fields are 
transmitted from left to right. 

0 12 

012345678901234567890 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | Value . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
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Type 



The Type field is one octet. Up-to-date values of the RADIUS Type 
field are specified in the most recent "Assigned Numbers" RFC [3] . 
Values 192-223 are reserved for experimental use, values 224-240 
are reserved for implementation-specific use, and values 241-255 
are reserved and should not be used. This specification concerns 
the following values: 

A RADIUS server MAY ignore Attributes with an unknown Type. 
A RADIUS client MAY ignore Attributes with an unknown Type. 



.1 User-Name 

2 User-Password 

3 CHAP-Password 

4 NAS- IP-Address 
' 5 NAS-Port 

6 Service-Type 

7 Framed-Protocol 

- 8 F r amed - 1 P - Addr e s s 

9 Framed- IP-Netmask 

10 Framed-Routing 

11 Filter-Id 

12 Framed-MTU 

13 Framed-Compression 

14 Login-IP-Host 

15 Login-Service 

16 Login-TCP-Port 

17 (unassigned) 

18 Reply-Message 

19 Callback-Number 

20 Callback-Id 

21 (unassigned) 

22 Framed-Route 

23 Framed-IPX-Network 

24 State 

25 Class 

2 6 Vendor - Spec i f i c 
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27 Session-Timeout 

28 Idle-Timeout 

29 Termination-Action 

30 Called-Station-Id 

31 Calling-Station- Id 

32 NAS-Identif ier 

33 Proxy-State 

34 Login-LAT-Service 
3 5 Login -LAT-Node 

3 6 Login-LAT-Group 

37 Framed-AppleTalk-Link 

38 F r amed - App 1 eTa 1 k -Ne twor k 
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39 


Framed-AppleTalk-Zone 


40-59 


(reserved for accounting) 


60 


CHAP-Challenge 


61 


NAS- Port -Type 


62 


Port-Limit 


63 


Login-LAT-Port 



Length 

The Length field is one octet, and indicates the length of this 
Attribute including the Type, Length and Value fields. If an 
Attribute is received in an Access-Request but with an invalid 
Length, an Access-Reject SHOULD be transmitted. If an Attribute 
is received in an Access-Accept, Access-Reject or Access-Challenge 
packet with an invalid length, the packet MUST either be treated 
an Access-Reject or else silently discarded. 

Value 

The Value field is zero or more octets and contains information 
specific to the Attribute. The format and length of the Value 
field is determined by the Type and Length fields. 

Note that a "string" in RADIUS does not require termination by an 
ASCII NUL because the Attribute already has a length field. 
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The .format of the value field is one of four data types, 
string 0-253 octets 

address 32 bit value, most significant octet first. 

integer 32 bit value, most significant octet first. 

time 32 bit value, most significant octet first -- seconds 

since 00:00:00 GMT, January 1, 1970. The standard 
Attributes do not use this data type but it is presented 
here for possible use within Vendor-Specific attributes. 



5.1. User-Name 
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Description 

This Attribute indicates the name of the user to be authenticated. 
It is only used in Access-Request packets. 

A summary of the User-Name Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 

0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

1 for User-Name. 
Lengt'h 

>= 3 
String 

The String field is one or more octets. The NAS may limit the 
maximum length of the User-Name but the ability to handle at least 
63 octets is recommended. 
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The format of the username MAY be one of several forms: 

monolithic Consisting only of alphanumeric characters. This 
simple form might be used to locally manage a NAS. 

simple Consisting only of printable ASCII characters. 

name@fqdn SMTP address. The Fully Qualified Domain Name (with or 
without trailing dot) indicates the realm in which the 
name part applies. 

distinguished name 

A name in ASN.l form used in Public Key authentication 
systems . 

5.2. User-Password 

Description 

This Attribute indicates the password of the user to be 



http://rfc.net/rfc2 1 38.txt 



12/28/2004 



Page 21 of 61 



authenticated, or the user's input following an Access-Challenge. 
It is only used in Access-Request packets. 

On transmission, the password is hidden. The password is first 
padded at the end with nulls to a multiple of 16 octets. A one- 
way MD5 hash is calculated over a stream of octets consisting of 
the shared secret followed by the Request Authenticator . This 
value is XORed with the first 16 octet segment of the password and 
placed in the first 16 octets of the String field of the User- 
Password Attribute. 

If the password is longer than 16 characters, a second one-way MD5 
Hash is calculated over a stream of octets consisting of the 
shared secret followed by the result of the first xor. That hash 
is XORed with the second 16 octet segment of the password and 
placed in the second 16 octets of the String field of the User- 
Password Attribute. 

If necessary, this operation is repeated, with each xor result 
being used along with the shared secret to generate the next hash 
to. xor the next segment of the password, to no more than 128 
characters . 

The method is taken from the book "Network Security" by Kaufman, 
Perlman and Speciner [4] pages 109-110. A more precise 
explanation of the method follows: 
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Call the shared secret S and the pseudo-random 12 8 -bit Request 
Authenticator RA. Break the password into 16 -octet chunks pi, p2 , 
etc. with the last one padded at the end with nulls to a 16-octet 
boundary. Call the ciphertext blocks c(l), c(2), etc. We'll need 
intermediate values bl, b2 , etc. 



bl = MD5(S + RA) c(l) = pi xor bl 

b2 = MD5(S + c(l)) c(2) =p2 xor b2 



bi = MD5(S + c(i-l)) c(i) = pi xor bi 

The String will contain c (1) +c (2 ) + . . . +c (i) where + denotes 
concatenation. 

On receipt, the process is reversed to yield the original 
password. 

A summary of the User-Password Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 
0123456789012345678901 
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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 



Type 

2 for User-Password. 
Length 

At least 18 and no larger than 130. 
String 

The String field is between 16 and 128 octets long, inclusive. 
5.3. CHAP-Password 
Description 

This Attribute indicates the response value provided by a PPP 
Challenge-Handshake Authentication Protocol (CHAP) user in 
response to the challenge. It is only used in Access-Request 
packets . 
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The CHAP challenge value is found in the CHAP-Challenge Attribute 
(60) if present in the packet, otherwise in the Request 
Authenticator field. 

A summary of the CHAP-Password Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 

012345678901234567890123456789 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | CHAP Ident | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_ 

Type 

3 for CHAP-Password. 
Length 
19 

CHAP Ident 

This field is one octet, and contains the CHAP Identifier from the 
user's CHAP Response. 

String 
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The String field is 16 octets, and contains the CHAP Response from 
the user. 

5.4. NAS- IP -Address 

Description 

This Attribute indicates the identifying IP Address of the NAS 
which is requesting authentication of the user. It is only used 
in Access-Request packets. Either NAS -IP- Address or NAS- 
Identifier SHOULD be present in an Access-Request packet. 
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A summary of the NAS -IP- Address Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Address 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Address (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

4 for NAS- IP-Address . 
Length 
6 

Address 

The Address field is four octets. 
5.5. NAS-Port 
Description 

This Attribute indicates the physical port number of the NAS which 
is authenticating the user. It is only used in Access-Request 
packets. Note that this is using "port" in its sense of a 
physical connection on the NAS, not in the sense of a TCP or UDP 
port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD 
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be present in an Access-Request packet, if the NAS differentiates 
among its ports. 

A summary of the NAS-Port Attribute format is shown below. The 
fields are transmitted from left to right. 
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0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

5 for NAS-Port. 
Length 

6 

Value 

The Value field is four octets. Despite the size of the field, 
values range from 0 to 65535. 

5.6. Service-Type 

Description 

This Attribute indicates the type of service the user has 
requested, or the type of service to be provided. It MAY be used 
in both Access-Request and Access-Accept packets. A NAS is not 
required to implement all of these service types, and MUST treat 
unknown or unsupported Service-Types as though an Access-Reject 
had been received instead. 

A summary of the Service-Type Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 3 
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01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

6 for Service-Type. 



Rigney, et . al . Standards Track [Page 26] 

□ 

RFC 2138 RADIUS April 1997 



Length 
6 

Value 

The Value field is four octets. 

1 Login 

2 Framed 

3 Callback Login 

4 Callback Framed 

5 Outbound 

6 Administrative 

7 NAS Prompt 

8 Authenticate Only 

9 Callback NAS Prompt 



The service types are defined as follows when used in an Access- 
Accept. When used in an Access-Request, they should be considered 
to be a hint to the RADIUS server that the NAS has reason to 
believe the user would prefer the kind of service indicated, but 
the server is not required to honor the hint. 



Login 
Framed 

Callback Login 
Callback Framed 

Outbound 



The user should be connected to a host. 

A Framed Protocol should be started for the 
User, such as PPP or SLIP. 

The user should be disconnected and called 
back, then connected to a host. 

The user should be disconnected and called 
back, then a Framed Protocol should be started 
for the User, such as PPP or SLIP. 

The user should be granted access to outgoing 
devices . 
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A*dmini strati ve The user should be granted access to the 

administrative interface to the NAS from which 
privileged commands can be executed. 

NAS Prompt The user should be provided a command prompt 

on the NAS from which non-privileged commands 
can be executed. 
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Authenticate Only 



Only Authentication is requested, and no 
authorization information needs to be returned 
in the Access-Accept (typically used by proxy 
servers rather than the NAS itself) . 



Callback NAS Prompt The user should be disconnected and called 

back, then provided a command prompt on the 
NAS from which non-privileged commands can be 
executed. 



5.7. Framed- Protocol 
Description 



This Attribute indicates the framing to be used for framed access. 
It MAY be used in both Access-Request and Access-Accept packets. 

A summary of the Framed-Protocol Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



Type 

7 for Framed-Protocol . 



Length 



6 

Value 



The Value field is four octets. 



1 PPP 

2 SLIP 

3 AppleTalk Remote Access Protocol (ARAP) 

4 Gandalf proprietary SingleLink/MultiLink protocol 
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5 Xylogics proprietary IPX/SLIP 
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5.8. Framed-IP-Address 
Description 

This Attribute indicates the address to be configured for the 
user. It MAY be used in Access-Accept packets. It MAY be used in 
an Access-Request packet as a hint by the NAS to the server that 
it would prefer that address, but the server is not required to 
honor the hint . 

A summary of the Framed-IP-Address Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Address 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Address (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

8 for Framed-IP-Address. 
Length 
6 

Address 

The Address field is four octets. The value OxFFFFFFFF indicates 
that the NAS should allow the user to select an address (e.g. 
Negotiated) . The value OxFFFFFFFE indicates that the NAS should 
select an address for the user (e.g. Assigned from a pool of 
addresses kept by the NAS) . Other valid values indicate that the 
NAS should use that value as the user's IP address. 

5.9. Framed- I P-Netmask 
Description 

This Attribute indicates the IP netmask to be configured for the 

user when the user is a router to a network. It MAY be used in 

Access-Accept packets. It MAY be used in an Access-Request packet 

as a hint by the NAS to the server that it would prefer that 

netmask, but the server is not required to honor the hint. 
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A summary of the Framed- IP-Netmask Attribute format is shown below. 
The fields are transmitted from left to right. 

0 1 2 3 

01234567890123456789012345678901 
+ _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

| Type | Length | Address 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Address (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

9* for Framed-IP-Netmask. 
Length 
6 

Address 

The Address field is four octets specifying the IP netmask of the 
user. 

5.10. Framed-Routing 
Description 

This Attribute indicates the routing method for the user, when the 
user is a router to a network. It is only used in Access-Accept 
packets . 

A summary of the Framed-Routing Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



Type 

10 for Framed-Routing. 
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Length 
6 

Value 

The Value field is four octets. 

0 None 

1 Send routing packets 

2 Listen for routing packets 

3 Send and Listen 

5.11. Filter-Id 
Description 

This Attribute indicates the name of the filter list for this 
user. Zero or more Filter-Id attributes MAY be sent in an 
Access-Accept packet. 

Identifying a filter list by name allows the filter to be used on 
different NASes without regard to filter-list implementation 
details . 

A summary of the Filter-Id Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 

0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

11 for Filter-Id. 
Length 
> = 3 
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• String 

The String field is one or more octets, and its contents are 
implementation dependent. It is intended to be human readable and 
MUST NOT affect operation of the protocol. It is recommended that 
the message contain displayable ASCII characters from the range 32 
through 126 decimal. 

5.12. Framed-MTU 

Description 

This Attribute indicates the Maximum Transmission Unit to be 
configured for the user, when it is not negotiated by some other 
means (such as PPP) . It is only used in Access-Accept packets. 

A summary of the Framed-MTU Attribute format is shown below. The 
fields are transmitted from left to right. 
♦ 

0 12 3 

01234567890123456789012345678901 

+-+-4--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

-» — i — i — i — i — i — i — i — i — i — t — i — i — i — i — i — i — i — i — j — i — t — i — i — i — i — i — j — i — * — t — i — i- 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

12 for Framed-MTU. 
Length 
6 

Value 

The Value field is four octets. Despite the size of the field, 
values range from 64 to 65535. 
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5.13. Framed-Compression 
Description 
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This Attribute indicates a compression protocol to be used for the 
link. It MAY be used in Access-Accept packets. It MAY be used in 
an Access-Request packet as a hint to the server that the NAS 
would prefer to use that compression, but the server is not 
required to honor the hint . 

More than one compression protocol Attribute MAY be sent. It is 
the responsibility of the NAS to apply the proper compression 
protocol to appropriate link traffic. 

A summary of the Framed-Compression Attribute format is shown below. 
The fields are transmitted from left to right. 

0 1 2 3 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-*+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

13 for Framed-Compression. 
Length 
6 

Value 

The Value field is four octets. 

0 None 

1 VJ TCP/IP header compression [5] 

2 IPX header compression 

5.14. Login-IP-Host 
Description 

This Attribute indicates the system with which to connect the 
user, when the Login-Service Attribute is included. It MAY be 
used in Access-Accept packets. It MAY be used in an Access- 
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Request packet as a hint to the server that the NAS would prefer 
to use that host, but the server is not required to honor the 
hint . 

A summary of the Login-IP-Host Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 3 



http://rfc.net/rfc2 1 38.txt 



Page 32 of 61 



01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Address 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Address {cont) | 

+ - + - + - + - + - + - + --H-+- + - + - + - + - + - + - + - + 

Type 

14 for Login-IP-Host. 
Length 
6 

Address 

The Address field is four octets. The value OxFFFFFFFF indicates 
fehat the NAS SHOULD allow the user to select an address. The 
value 0 indicates that the NAS SHOULD select a host to connect the 
user to. Other values indicate the address the NAS SHOULD connect 
the user to. 

5.15. Login-Service 

Description 

This Attribute indicates the service which should be used to 
connect the user to the login host. It is only used in Access- 
Accept packets . 

A summary of the Login-Service Attribute format is shown below. The 
fields are transmitted from left to right. 
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0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 



Type 

15 for Login-Service. 
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Length 
6 

Value 

The Value field is four octets. 

0 Telnet 

1 Rlogin 

2 TCP Clear 

3 PortMaster (proprietary) 

4 LAT 

, 16 .- Login-TCP-Port 
Description 

This Attribute indicates the TCP port with which the user is to be 
connected, when the Login-Service Attribute is also present. It 
is only used in Access-Accept packets. 
A summary of the Login-TCP- Port Attribute format is shown below. The 
fields are transmitted from left to rxght. 

2 3 



0123456789012345 6 7 8 9 + + - + 

*-+-+-+- 

Length 



^^*^^^- r ~~~ 

U^ t -.-J----^-----l — 



Value (cont) 
+_ + -+-+-+-+-+-+-+-+-+-+-+-+- + - + - + 

Type 

16 for Login-TCP-Port. 

iPaoe 35 ' 

Length 
6 

Value 

The Value field is four octets. Despite the size of the field, 

values range from 0 to 65535. 

5.17. (unassigned) 
Description 

ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED. 

5.18. Reply-Message 
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Description 

This Attribute indicates text which MAY be displayed to the user. 

When used in an Access-Accept, it is the success message. 

When used in an Access-Reject, it is the failure message. It MAY 
indicate a dialog message to prompt the user before another 
Access-Request attempt. 

When used in an Access-Challenge, it MAY indicate a dialog message 
to prompt the user for a response. 

Multiple Reply-Message's MAY be included and if any are displayed, 
they MUST be displayed in the same order as they appear in the 
packet . 

A summary of the Reply-Message Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 

0123456789012345678901 
+_+_+_+_+_+_ + _+_ + _ + _+_ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ 

| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 



Type 

18 for Reply-Message. 
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Length 

> = 3 
String 

The String field is one or more octets, and its contents are 
implementation dependent. It is intended to be human readable, 
and MUST NOT affect operation of the protocol. It is recommended 
that the message contain displayable ASCII characters from the 
range 10, 13, and 32 through 12 6 decimal. Mechanisms for 
extension to other character sets are beyond the scope of this 
specification . 

5.19. Callback-Number 

Description 

This Attribute indicates a dialing string to be used for callback. 
It MAY be used in Access-Accept packets. It MAY be used in an 
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Access-Request packet as a hint to the server that a Callback 
service is desired, but the server is not required to honor the 
hint. 

A summary of the Call back -Number Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 
0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

19 for Callback-Number. 
Length 
>= 3 
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String 

The String field is one or more octets. The actual format of the 
information is site or application specific, and a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 



5.20. Callback-Id 



Description 



This Attribute indicates the name of a place to be called, to be 
interpreted by the NAS . It MAY be used in Access-Accept packets. 

A summary of the Callback-Id Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 
0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_+_+_+-+_ 

I Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_+-+-+-+- 
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Type 

20 for Callback-Id. 
Length 

>= 3 
String 

The String field is one or more octets. The actual format of the 
information is site or application specific, and a robust 
implementation SHOULD support the field as undistinguished octets. 
The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

5.21. -(unassigned) 

Description 
* 

ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED. 
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5.22. Framed-Route 
Description 

This Attribute provides routing information to be configured for 
the user on the NAS. It is used in the Access-Accept packet and 
can appear multiple times. 

A summary of the Framed-Route Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 
012345678901234567890123 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | String... 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

22 for Framed-Route. 
Length 

>= 3 
String 

The String field is one or more octets, and its contents are 
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•implementation dependent. It is intended to be human readable and 
MUST NOT affect operation of the protocol. It is recommended that 
the message contain displayable ASCII characters from the range 32 
through 12 6 decimal. 

For IP routes, it SHOULD contain a destination prefix in dotted 
quad form optionally followed by a slash and a decimal length 
specifier stating how many high order bits of the prefix should be 
used. That is followed by a space, a gateway address in dotted 
quad form, a space, and one or more metrics separated by spaces. 
For example, "192.168.1.0/24 192.168.1.1 12-13 400". The length 
specifier may be omitted in which case it should default to 8 bits 
for class A prefixes, 16 bits for class B prefixes, and 24 bits 
for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 

Whenever the gateway address is specified as "0.0.0.0" the IP 
address of the user SHOULD be used as the gateway address. 
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5.23. Framed-IPX-Network 
Description 

This Attribute indicates the IPX Network number to be configured 
for the user. It is used in Access-Accept packets. 

A summary of the Framed-IPX-Network Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -+- + - + --«-- + - + - + - + - + - + - + - + - + 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

23 for Framed-IPX-Network. 
Length 
6 

Value 

The Value field is four octets. The value OxFFFFFFFE indicates 
that the NAS should select an IPX network for the user (e.g. 
assigned from a pool of one or more IPX networks kept by the NAS) . 
Other values should be used as the IPX network for the link to the 
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user. 
5.24. State 
Description 

This Attribute is available to be sent by the server to the client 
in an Access-Challenge and MUST be sent unmodified from the client 
to the server in the new Access -Request reply to that challenge, 
if any. 
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This Attribute is available to be sent by the server to the client 
in an Access-Accept that also includes a Termination-Action 
Attribute with the value of RADIUS -Reques t . If the NAS performs 
the Termination-Action by sending a new Access-Request upon 
termination of the current session, it MUST include the State 
attribute unchanged in that Access -Request . 

In either usage, no interpretation by the client should be made. 
A packet may have only one State Attribute. Usage of the State 
Attribute is implementation dependent. 

A summary of the State Attribute format is shown below. The fields 
are transmitted from left to right. 

0 12 
0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | String . . . 

+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ 

Type 

24 for State. 
Length 

>= 3 
String 

The String field is one or more octets. The actual format of the 
information is site or application specific, and a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 
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5.25. Class 
Description 

This Attribute is available to be sent by the server to the client 
in an Access-Accept and should be sent unmodified by the client to 
the accounting server as part of the Accounting-Request packet if 
accounting is supported. No interpretation by the client should 
be made . 
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A summary of the Class Attribute format is shown below. The fields 
are ..transmitted from left to right. 

.0 1 2 

0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | String . . . 

+ - + -+- + - + - + - + - + - + - + - + - + - + -+- + - + - + - + - + - + --!-- + - + - 

Type 

25 for Class. 
Length 

>= 3 
String 

The String field is one or more octets. The actual format of the 
information is site or application specific, and a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

5.26. Vendor-Specific 

Description 

This Attribute is available to allow vendors to support their own 
extended Attributes not suitable for general usage. It MUST not 
affect the operation of the RADIUS protocol. 

Servers not equipped to interpret the vendor-specific information 
sent by a client MUST ignore it (although it may be reported) . 
Clients which do not receive desired vendor-specific information 
SHOULD make an attempt to operate without it, although they may do 
so (and report they are doing so) in a degraded mode. 
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A summary of the Vendor-Specific Attribute format is shown below. 
The fields are transmitted from left to right. 
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0 12 3 

01234567890123456789012345678901 
, + _ + ^ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + _ + 

| Type | Length | Vendor-Id 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

- Vendor-Id (cont) | String. . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 



Type 



26 for Vendor-Specific. 



Length 
>= 7 



Vendor- Id 



The high-order octet is 0 and the low-order 3 octets are the SMI 
Network Management Private Enterprise Code of the Vendor in 
network byte order, as defined in the Assigned Numbers RFC [3] . 

String 

The String field is one or more octets. The actual format of the 
information is site or application specific, and a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

It SHOULD be encoded as a sequence of vendor type / vendor length 
/ value fields, as follows. The Attribute-Specific field is 
dependent on the vendor's definition of that attribute. An 
example encoding of the Vendor-Specific attribute using this 
method follows: 

0 1 2 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Type | Length | Vendor-Id 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor- Id (cont) | Vendor type | Vendor length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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^| Attribute-Specific. . . 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
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5.27. Session-Timeout 
Description 

This Attribute sets the maximum number of seconds of service to be 
provided to the user before termination of the session or prompt. 
This Attribute is available to be sent by the server to the client 
in an Access-Accept or Access-Challenge. 

A summary of the Session-Timeout Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

27 for Session-Timeout. 
Length 
6 

Value 

The field is 4 octets, containing a 32-bit unsigned integer with 
the maximum number of seconds this user should be allowed to 
remain connected by the NAS . 

5.28. Idle-Timeout 
Description 

This Attribute sets the maximum number of consecutive seconds of 
idle connection allowed to the user before termination of the 
session or prompt. This Attribute is available to be sent by the 
server to the client in an Access-Accept or Access-Challenge. 
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A summary of the Idle-Timeout Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

28 for Idle-Timeout. 
Length 

6 

Value 

The field is 4 octets, containing a 32-bit unsigned integer with 
the maximum number of consecutive seconds of idle time this user 
should be permitted before being disconnected by the NAS . 

5.29. Termination-Action 

Description 

This Attribute indicates what action the NAS should take when the 
specified service is completed. It is only used in Access-Accept 
packets . 

A summary of the Termination-Action Attribute format is shown below. 
The fields are transmitted from left to right. 

0.1 2 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

29 for Termination-Action. 
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Length 



6 



Value 



The Value field is four octets. 



0 
1 



Default 

RADIUS-Request 



If the Value is set to RADIUS-Request, upon termination of the 
specified service the NAS MAY send a new Access-Request to the 
RADIUS server, including the State attribute if any. 

5.30. Called-Station-Id 

Description 

This Attribute allows the NAS to send in the Access-Request packet 
the phone number that the user called, using Dialed Number 
Identification (DNIS) or similar technology. Note that this may be 
different from the phone number the call comes in on. It is only 
used in Access-Request packets. 

A summary of the Called-Station-Id Attribute format is shown below. 
The fields are transmitted from left to right. 



0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

30 for Called-Station-Id. 
Length 

>= 3 
String 

The String field is one or more octets, containing the phone 
number that the user's call came in on. 
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-The actual format of the information is site or application 
specific. Printable ASCII is recommended, but a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

5.31. Calling-Station-Id 

Description 

This Attribute allows the NAS to send in the Access-Request packet 
the phone number that the call came from, using Automatic Number 
Identification (AND or similar technology. It is only used in 
Access-Request packets. 

A summary of the Calling-Stat ion-Id Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 

0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

31 for Calling-Station-Id. 
Length 

>= 3 
String 

The String field is one or more octets, containing the phone 
number that the user placed the call from. 

The actual format of the information is site or application 
specific. Printable ASCII is recommended, but a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 
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5 .32 . NAS-Identif ier 
Description 
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This Attribute contains a string identifying the NAS originating 
the Access-Request. It is only used in Access -Request packets. 
Either NAS -IP- Address or NAS-Identif ier SHOULD be present in an 
Access-Request packet. 

A summary of the NAS-Identif ier Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 
012 3 456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

32 for NAS-Identif ier. 
Length 

>= 3 
String 

The String field is one or more octets, and should be unique to 
the NAS within the scope of the RADIUS server. For example, a 
fully qualified domain name would be suitable as a NAS-Identif ier . 

The actual format of the information is site or application 
specific, and a robust implementation SHOULD support the field as 
undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

5.33. Proxy-State 

Description 

This Attribute is available to be sent by a proxy server to 
another server when forwarding an Access -Request and MUST be 
returned unmodified in the Access-Accept, Access-Reject or 
Access-Challenge. This attribute should be removed by the proxy 
server before the response is forwarded to the NAS. 
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Usage of the Proxy-State Attribute is implementation dependent. A 
description of its function is outside the scope of this 
specification . 

A summary of the Proxy-State Attribute format is shown below. The 
fields are transmitted from left to right. 
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0.,1 23456789012345678901 
+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ 

| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

33 for Proxy-State. 
Length 

>= 3 
String 

The String field is one or more octets. The actual format of the 
information is site or application specific, and a robust 
implementation SHOULD support the field as undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

5.34. Login-LAT-Service 

Description 

This Attribute indicates the system with which the user is to be 
connected by LAT. It MAY be used in Access-Accept packets, but 
only when LAT is specified as the Login-Service. It MAY be used 
in an Access-Request packet as a hint to the server, but the 
server is not required to honor the hint. 

Administrators use the service attribute when dealing with 
clustered systems, such as a VAX or Alpha cluster. In such an 
environment several different time sharing hosts share the same 
resources (disks, printers, etc.), and administrators often 
configure each to offer access (service) to each of the shared 
resources. In this case, each host in the cluster advertises its 
services through LAT broadcasts. 
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Sophisticated users often know which service providers (machines) 
are faster and tend to use a node name when initiating a LAT 
connection. Alternately, some administrators want particular 
users to use certain machines as a primitive form of load 
balancing (although LAT knows how to do load balancing itself) . 

A summary of the Login-LAT-Service Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 

0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+_+_+_+_+_+_+_+_+_+_+_ 
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| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 



Type 

34 for Login-LAT-Service . 
Length 

>= 3 
String 

The String field is one or more octets, and contains the identity 
of the LAT service to use. The LAT Architecture allows this 
string to contain $ (dollar) , - (hyphen) , . (period) , _ 
.(underscore) , numerics, upper and lower case alphabet ics, and the 
ISO .Latin-1 character set extension [6] . All LAT string 
comparisons are case insensitive. 

5.35. Login-LAT-Node 

Description 

This Attribute indicates the Node with which the user is to be 
automatically connected by LAT. It MAY be used in Access-Accept 
packets, but only when LAT is specified as the Login-Service. It 
MAY be used in an Access-Request packet as a hint to the server, 
but the server is not required to honor the hint. 

A summary of the Login-LAT-Node Attribute format is shown below. The 
fields are transmitted from left to right. 
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0 12 
0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

35 for Login-LAT-Node. 
Length 

>= 3 
String 
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♦The String field is one or more octets, and contains the identity 
of the LAT Node to connect the user to. The LAT Architecture 
allows this string to contain $ (dollar) , - (hyphen) , . (period) , 
_ (underscore) , numerics, upper and lower case alphabetics, and 
the ISO Latin-1 character set extension. All LAT string 
comparisons are case insensitive. 

5.36. Login-LAT-Group 

Description 

This Attribute contains a string identifying the LAT group codes 
which this user is authorized to use. It MAY be used in Access- 
Accept packets, but only when LAT is specified as the Login- 
Service. It MAY be used in an Access-Request packet as a hint to 
the server, but the server is not required to honor the hint. 

LAT supports 256 different group codes, which LAT uses as a form 
'of access rights. LAT encodes the group codes as a 256 bit 
bitmap . 

Administrators can assign one or more of the group code bits at 
the LAT service provider; it will only accept LAT connections that 
have these group codes set in the bit map. The administrators 
assign a bitmap of authorized group codes to each user; LAT gets 
these from the operating system, and uses these in its requests to 
the service providers . 
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A summary of the Login-LAT-Group Attribute format is shown below. 
The fields are transmitted from left to right. 

0 12 
0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

I Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_ 

Type 

3 6 for Login-LAT-Group. 
Length 

34 
String 

The String field is a 32 octet bit map, most significant octet 
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first. A robust implementation SHOULD support the field as 
undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 

5.37. Framed-AppleTalk-Link 

Description 

This Attribute indicates the AppleTalk network number which should 
be used for the serial link to the user, which is another 
AppleTalk router. It is only used in Access-Accept packets. It 
is never used when the user is not another router. 

A summary of the Framed-AppleTalk-Link Attribute format is shown 
below. ■ The fields are transmitted from left to right. 

0 1 2 3 

01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
I Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_+-+-+-+_+_+_+_+_+_+-+_+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Type 

37 for Framed-AppleTalk-Link. 
Length 
6 

Value 

The Value field is four octets. Despite the size of the field, 
values range from 0 to 65535. The special value of 0 indicates 
that this is an unnumbered serial link. A value of 1-65535 means 
that the serial line between the NAS and the user should be 
assigned that value as an AppleTalk network number. 

5.38. Framed-AppleTalk-Network 

Description 

This Attribute indicates the AppleTalk Network number which the 
NAS should probe to allocate an AppleTalk node for the user. It 
is only used in Access-Accept packets. It is never used when the 
user is another router. Multiple instances of this Attribute 
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•.indicate that the NAS may probe using any of the network numbers 
specified. 

A summary of the Framed-AppleTalk-Network Attribute format is shown 
below. The fields are transmitted from left to right. 

0 12 3 

012 3 4567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+--f-+-+-+ -+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+ 
| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

38 for Framed-AppleTalk-Network. 
Length 
6 
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Value 

The Value field is four octets. Despite the size of the field, 
values range from 0 to 65535. The special value 0 indicates that 
the NAS should assign a network for the user, using its default 
cable range. A value between 1 and 65535 (inclusive) indicates 
the AppleTalk Network the NAS should probe to find an address for 
the user. 



5.39. Framed-AppleTalk-Zone 



Description 



This Attribute indicates the AppleTalk Default Zone to be used for 
this user. It is only used in Access-Accept packets. Multiple 
instances of this attribute in the same packet are not allowed. 

A summary of the Framed-AppleTalk-Zone Attribute format is shown 
below. The fields are transmitted from left to right. 

0 1 2 

0123456789012345678901234 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

I Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+_+_+_+_+_+_+_+_+_+_+_+_+_ 

Type 
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39 for Framed-AppleTalk-Zone . 
Length 

>= 3 
String 

The name of the Default AppleTalk Zone to be used for this user. 
A robust implementation SHOULD support the field as 
undistinguished octets. 

The codification of the range of allowed usage of this field is 
outside the scope of this specification. 
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5.40. CHAP-Challenge 
Description 

This Attribute contains the CHAP Challenge sent by the NAS to a 
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It 
is only used in Access-Request packets. 

If the CHAP challenge value is 16 octets long it MAY be placed in 
the Request Authenticator field instead of using this attribute. 

A summary of the CHAP-Challenge Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 

012345678901234567890123 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| Type | Length | String. . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 

Type 

60 for CHAP-Challenge. 
Length 

>= 7 
String 

The String field contains the CHAP Challenge. 
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5.41. •* NAS- Port -Type 
Description 

This Attribute indicates the type of the physical port of the NAS 
which is authenticating the user. It can be used instead of or in 
addition to the NAS-Port (5) attribute. It is only used in 
Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or 
both SHOULD be present in an Access-Request packet, if the NAS 
differentiates among its ports. 
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A summary of the NAS-Port-Type Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 3 

01234567890123456789012345678901 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+ 

| Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

61 for NAS-Port-Type. 
Length 
6 

Value 

The Value field is four octets. "Virtual" refers to a connection 
to the NAS via some transport protocol, instead of through a 
physical port. For example, if a user telnetted into a NAS to 
authenticate himself as an Outbound-User, the Access-Request might 
include NAS-Port-Type = Virtual as a hint to the RADIUS server 
that the user was not on a physical port. 

0 Async 

1 Sync 

2 ISDN Sync 

3 ISDN Async V.120 

4 ISDN Async V. 110 

5 Virtual 

5.42. Port-Limit 
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Description 

This Attribute sets the maximum number of ports to be provided to 
the user by the NAS . This Attribute MAY be sent by the server to 
the client in an Access-Accept packet. It is intended for use in 
conjunction with Multilink PPP [7] or similar uses. It MAY also 
be sent by the NAS to the server as a hint that that many ports 
are desired for use, but the server is not required to honor the 
hint . 
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A summary of the Port-Limit Attribute format is shown below. The 
fields are transmitted from left to right. 

0 1 2 3 

01234567890123456789012345678901 

I Type | Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+_+_+ _+_+_+_+_+ 

Value (cont) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Type 

62 for Port-Limit. 
Length 
6 

Value 

The field is 4 octets, containing a 32-bit unsigned integer with 
the maximum number of ports this user should be allowed to connect 
to on the NAS. 

5.43. Login-LAT-Port 

Description 

This Attribute indicates the Port with which the user is to be 
connected by LAT. It MAY be used in Access-Accept packets, but 
only when LAT is specified as the Login-Service. It MAY be used 
in an Access-Request packet as a hint to the server, but the 
server is not required to honor the hint. 

A summary of the Login-LAT-Port Attribute format is shown below. The 
fields are transmitted from left to right. 

0 12 
0123456789012345678901 
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+ --T- + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - 

| Type | Length | String . . . 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 



Type 

63 for Login-LAT-Port . 
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Length 

^= 3 
String 

The String field is one or more octets, and contains the identity 
of the LAT port to use. The LAT Architecture allows this string 
to contain $ (dollar) , - (hyphen) , . (period) , _ (underscore) , 
numerics, upper and lower case alphabetics, and the ISO Latin-1 
character set extension. All LAT string comparisons are case 
insensitive . 



5.44. Table of Attributes 



The following table provides a guide to which attributes may be found 
in which kinds of packets, and in what quantity. 



Request 


Accept 


Reject 


Challenge 


# 


Attribute 


1 


0 


0 


0 


1 


User-Name 


0-1 


0 


0 


0 


2 


User- Password [Note 


0-1 


0 


0 


0 


3 


CHAP- Password [Note 


0-1 


0 


0 


0 


4 


NAS- IP-Address 


0-1 


0 


0 


0 


5 


NAS-Port 


0-1 


0-1 


0 


0 


6 


Service-Type 


0-1 


0-1 


0 


0 


7 


Framed- Protocol 


0-1 


0-1 


0 


0 


8 


Framed- IP- Address 


0-1 


0-1 


0 


0 


9 


Framed- I P-Netmask 


0 


0-1 


0 


0 


10 


Framed-Routing 


0 


0 + 


0 


0 


11 


Filter-Id 


0 


0-1 


0 


0 


12 


Framed-MTU 


0 + 


0 + 


0 


0 


13 


Framed-Compression 


0 + 


0 + 


0 


0 


14 


Login-IP-Host 


0 


0-1 


0 


0 


15 


Login -Service 


0 


0-1 


0 


0 


16 


Login-TCP-Port 


0 


0 + 


0 + 


0 + 


18 


Reply-Message 


0-1 


0-1 


0 


0 


19 


Callback-Number 


0 


0-1 


0 


0 


20 


Callback-Id 


0 


0 + 


0 


0 


22 


Framed-Route 


0 


0-1 


0 


0 


23 


Framed - 1 PX -Ne two r k 


0-1 


0-1 


0 


0-1 


24 


State 


0 


0 + 


0 


0 


25 


Class 


0 + 


0+ . 


0 


0 + 


26 


Vendor- Spec if ic 


0 


0-1 


0 


0-1 


27 


Session-Timeout 
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o-i 
o-i 

0 
0 



0-1 
0 
0 
0 



2 8 Idle-Timeout 

29 Termination-Action 

3 0 Called-Station-Id 
31 Calling-Station- Id 
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0-1 


0 


0 


0 


32 


NAS-Identif ier 


0 + 


0 + 


0 + 


0 + 


33 


Proxy-State 


0-1 


0-1 


0 


0 


34 


Login-LAT- Service 


0-1 


0-1 


0 


0 


35 


Login -LAT-Node 


0-1 


0-1 


0 


0 


36 


Login-LAT-Group 


0 


0-1 


0 


0 


37 


Framed-AppleTalk-Link 


0 , 


0 + 


0 


0 


38 


Framed-AppleTalk-Network 


0 


0-1 


0 


0 


39 


Framed-AppleTalk-Zone 


0-1 


0 


0 


0 


60 


CHAP-Challenge 


0-1* 


0 


0 


0 


61 


NAS- Port -Type 


0-1 


0-1 


0 


0 


62 


Port-Limit 


0-1 


0-1 


0 


0 


63 


Login-LAT- Port 


Request 


Accept 


Reject 


Challenge 


# 


Attribute 



[Note 1] An Access-Request MUST contain either a User-Password or a 
CHAP-Password, and MUST NOT contain both. 

The following table defines the meaning of the above table entries. 

0 This attribute MUST NOT be present in packet. 

0+ Zero or more instances of this attribute MAY be present in packet. 
0-1 Zero or one instance of this attribute MAY be present in packet. 

1 Exactly one instance of this attribute MUST be present in packet. 

6 . Examples 

A few examples are presented to illustrate the flow of packets and 
use of typical attributes. These examples are not intended to be 
exhaustive, many others are possible. 
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6.1. User Telnet to Specified Host 

The NAS at 192.168.1.16 sends an Access-Request UDP packet to the 
RADIUS Server for a user named nemo logging in on port 3 . 

Code = 1 (Access-Request) 
ID = 0 
Length =56 

Request Authenticator = {16 octet random number} 
Attributes : 

, 7 User-Name = "nemo" 

User-Password = {16 octets of Password padded at end with nulls, 
XORed with MD5(shared secret | Request Authenticator)} 
h NAS -IP-Address = 192.168.1.16 

NAS-Port = 3 

The RADIUS server authenticates nemo, and sends an Access-Accept UDP 
packet to the NAS telling it to telnet nemo to host 192.168.1.3. 

Code = 2 (Access-Accept) 

ID = 0 (same as in Access -Request ) 

Length =38 

Response Authenticator = {16-octet MD-5 checksum of the code (2), 

id (0), Length (38), the Request Authenticator from 
above, the attributes in this reply, and the shared 
secret} 

Attributes : 

Service-Type = Login-User 
Login-Service = Telnet 
Login-Host =192.168.1.3 

6.2. Framed User Authenticating with CHAP 

The NAS at 192.168.1.16 sends an Access-Request UDP packet to the 
RADIUS Server for a user named flopsy logging in on port 20 with PPP, 
authenticating using CHAP. The NAS sends along the Service-Type and 
Framed-Protocol attributes as a hint to the RADIUS server that this 
user is looking for PPP, although the NAS is not required to do so. 



Rigney, et. al . 
http://rfc.net/rfc2138.txt 



Standards Track 



[Page 60] 



12/28/2004 



Page 57 of 61 



RFC 2138 RADIUS April 1997 



Code = 1 (Access-Request) 
ID = 1 
Length =71 

Request Authenticator = {16 octet random number also used as 

CHAP challenge} 

Attributes : 

User-Name = " flopsy" 

CHAP-Password = {1 octet CHAP ID followed by 16 octet 

CHAP response} 
NAS- IP- Address = 192.168.1.16 
NAS-Port = 20 

Service-Type = Framed-User 
Framed-Protocol = PPP 



The,, RADIUS server authenticates flopsy, and sends an Access-Accept 
UDP packet to the NAS telling it to start PPP service and assign an 
address for the user out of its dynamic address pool. 

Code = 2 (Access-Accept) 

ID = 1 (same as in Access -Request ) 

Length = 56 

Response Authenticator = {16-octet MD-5 checksum of the code (2), 

id (1) , Length (56) , the Request Authenticator from 
above, the attributes in this reply, and the shared 
secret} 

Attributes : 

Service-Type = Framed-User 
Framed-Protocol = PPP 
Framed-IP-Address = 255.2 55.255.254 
Framed-Routing = None 

Framed-Compression = 1 (VJ TCP/IP Header Compression) 

Framed-MTU = 1500 



6.3. User with Challenge-Response card 



The NAS at 192.168.1.16 sends an Access-Request UDP packet to the 
RADIUS Server for a user named mopsy logging in on port 7. 

Code = 1 (Access-Request) 
ID = 2 
Length = 57 

Request Authenticator = {16 octet random number} 
Attributes : 

User -Name = "mopsy" 

User-Password = {16 octets of Password padded at end with nulls, 
XORed with MD5 (shared secret | Request Authenticator)} 
NAS-IP-Address = 192.168.1.16 
NAS-Port = 7 
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n >The< RADIUS server decides to challenge mopsy, sending back a 

challenge string and looking for a response. The RADIUS server 
therefore and sends an Access-Challenge UDP packet to the NAS . 

Code = 11 (Access-Challenge} 

ID = 2 (same as in Access-Request) 

Length =78 

Response Authenticator = {16-octet MD-5 checksum of the code (11) , 
id (2), length (78), the Request Authenticator from 
above, the attributes in this reply , and the shared 
secret} 

Attributes: 

Reply-Message = "Challenge 32769430. Enter response at prompt." 
State = {Magic Cookie to be returned along with user's response; 

in this example 8 octets of data} 

The user enters his response, and the NAS send a new Access-Request 
with that response, and includes the State Attribute. 

Code = 1 (Access-Request) 

ID = 3 (Note that this changes) 

length = 67 

Request Authenticator = {NEW 16 octet random number} 
Attributes: 

User -Name = "mopsy" 

User-Password = {16 octets of Response padded at end with 

nulls, XORed with MD5 checksum of shared secret 
plus above Request Authenticator} 

NAS- IP-Address = 192.168.1.16 

NAS-Port = 7 

State = {Magic Cookie from Access-Challenge packet, unchanged} 

The Response was incorrect, so the RADIUS server tells the NAS to 
reject the login attempt. 

Code = 3 (Access-Reject) 

ID = 3 (same as in Access-Request) 

Length =20 

Response Authenticator = {16-octet MD-5 checksum of the code (3) , 
id (3), length (20), the Request Authenticator from 
above, the attributes in this reply if any, and the 
shared secret} 

Attributes : 

(none, although a Reply-Message could be sent) 



Rigney, et . al . Standards Track [Page 62] 

□ 

RFC 2138 RADIUS April 1997 



Security Considerations 

Security issues are the primary topic of this document. 
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* "'In^practice, within or associated with each RADIUS server, there is a 
database which associates "user" names with authentication 
information ("secrets"). It is not anticipated that a particular 
named user would be authenticated by multiple methods. This would 
make the user vulnerable to attacks which negotiate the least secure 
method from among a set. Instead, for each named user there should 
be an indication of exactly one method used to' authenticate that user 
name. If a user^ needs to make use of different authentication 
methods under different circumstances, then distinct user names 
SHOULD be employed, each of which identifies exactly one 
authentication method. 

Passwords and other secrets should be stored at the respective ends 
such that access to them is as limited as possible. Ideally, the 
secrets should only be accessible to the process requiring access in 
order to perform the authentication. 

The secrets should be distributed with a mechanism that limits the 
number of entities that handle (and thus gain knowledge of) the 
secret. Ideally, no unauthorized person should ever gain knowledge 
of the secrets. It is possible to achieve this with SNMP Security 
Protocols [8] , but such a mechanism is outside the scope of this 
specification . 

Other distribution methods are currently undergoing research and 
experimentation. The SNMP Security document [8] also has an 
excellent overview of threats to network protocols. 
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